home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 13022 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB
  1. Path: solon.com!not-for-mail
  2. From: schwarz@mips.complang.tuwien.ac.at (Konrad Schwarz)
  3. Newsgroups: comp.lang.c,comp.lang.c.moderated,hp.unix,comp.sys.hp.apps,comp.sys.hp.hpux
  4. Subject: Re: C coding problem
  5. Date: 3 Apr 1996 18:59:09 -0600
  6. Organization: TU Wien
  7. Sender: clc@solutions.solon.com
  8. Approved: clc@solutions.solon.com
  9. Message-ID: <4jv6st$crf@solutions.solon.com>
  10. References: <4ianbf$h86@solutions.solon.com> <4iemcl$a05@solutions.solon.com> <4io1io$no4@solutions.solon.com> <4j06na$808@solutions.solon.com> <4jttan$3gf@solutions.solon.com>
  11. NNTP-Posting-Host: solutions.solon.com
  12.  
  13. In article <4jttan$3gf@solutions.solon.com>, nsmart@indigo.ie (Niall Smart) writes:
  14. |> 
  15. |> >: I recently wrote a loop that went like this:
  16. |> 
  17. |> >: while (p < end_p)
  18. |> >:     ++*p++;
  19. |> 
  20. |> >: Maybe some will find it a counter-example; I think it's good
  21. |> >: code that embodies the way C is designed to work.  Arrays are
  22. |> >: second rate objects in C.  Use pointers.
  23. |> 
  24. |> That code scores negative for maintainability, why use arcane
  25. |> features of the language that can be replaced with more readable code?
  26.  
  27. My point is precisely that pointers should not be considered arcane.
  28.  
  29. |> If you read any of the books on writing good code you will find
  30. |> hundreds of reasons to avoid code like that. The execution time you
  31. |> *might* be saving is offset many times by the time it takes a
  32. |> maintainer to figure it out.
  33.  
  34. Execution time has nothing to do with it.
  35.  
  36. |> Secondly, why not use arrays? In many places they are easier to
  37. |> understand - I for one am not going to compromise the readability
  38. |> of my programs because of some theoretical bull about them
  39. |> being second rate objects. (whatever that is intended to mean)
  40.  
  41. You answer this question yourself below.
  42.  
  43. |> a[i] is converted to *(a + i) by the compiler in any case so
  44. |> whats the advantage with your approach?
  45.  
  46. The machine doesn't have to add, the machine doesn't have to multiply,
  47. *a is less complicated to understand than a [i] since only one variable
  48. is involved, *a is more type safe than a [i], since there is nothing
  49. constraining i (besides it being of integral type), the optimizer
  50. has less to do, compile time decreases, etc. 
  51.  
  52. Why use C if you're uncomfortable with pointer arithmetic?  Why use
  53. functional languages if you're uncomfortable with recursion?  Why use
  54. object-oriented languages if you're uncomfortable with objects?
  55.  
  56. Konrad Schwarz
  57.